[Config] [Kimi K3 fix] Drop gfx942/gfx950 opus rows from the BF16 tuned-GEMM tables - #4915

Motivation

The a16w16 split-K opus kernels keep their partial-sum buffer in a per-stream hipMalloc
registry on gfx942/gfx950. Any HIP graph capture that is the first thing to touch that registry
aborts:

[AITER] opus_gemm.cu:487 splitk workspace not initialized for the current CUDA stream.
Call aiter.opus_gemm_workspace_init() inside with torch.cuda.stream(s): ...

Frameworks that capture cudagraphs (vLLM, SGLang) never make that call — vLLM contains no
opus_gemm references at all — so every tuned row selecting libtype=opus on these two archs
is a latent engine crash for them. The row itself is fine in eager mode; it is only unusable
under capture.

gfx1250 is unaffected: #4246 gave it a torch.empty workspace (_get_opus_workspace) that is
HIP-graph-capture aware, and its docstring states "No eager pre-warm is required." Its opus
rows are therefore kept.

Technical Details

Removes 259 rows where libtype == "opus" and gfx ∈ {gfx942, gfx950}:

• 12 files touched, 259 deletions, 0 additions. No row is edited; whole lines are removed so
  every surviving byte is untouched.
• Removed shapes fall through get_GEMM_A16W16_config to its default branch (asm / skinny /
  torch), all capture-safe.
• Because the tuned table is indexed by ("gfx", "cu_num", ...), removing a row only affects the
  arch it names.

This is a mitigation, not the root fix. Porting #4246's torch.empty workspace to the
gfx942/gfx950 split-K kids would remove the per-stream registry entirely and let these rows come
back. That is the change I would rather see; this PR unblocks capture-mode users in the meantime.

Framework-side workarounds were tried first and are not sufficient — calling
opus_gemm_workspace_init() on the capture stream from vLLM
(vllm-project/vllm#53238, now closed) lets the PIECEWISE ladder finish but
the abort simply relocates to FULL capture, because the registry is per-stream and the framework
cannot reliably pre-register every stream that will capture.

Test Plan

Kimi-K3 MXFP4 TP8 (bf16 GEMM path), 8x MI355X (gfx950), ROCm 7.2.3, aiter v0.1.20, vLLM main
with cudagraphs enabled, --max-num-seqs 20 (concurrency 8, 48-entry PIECEWISE ladder).

1. Start the server with the stock tuned tables → observe the abort.
2. Start it with the opus rows removed → observe capture completing and the server serving.
3. Run gsm8k (5-shot, lm_eval, real verification sampling) to confirm numerics are unaffected.
4. Repeat at concurrency 1 to characterise the failure.

Step 2 was executed by pointing AITER_CONFIG_GEMM_BF16 at a table generated by the same rule.
On gfx950 that table is equivalent to this diff by construction: the lookup is arch-keyed, so the
gfx942/gfx1250 rows are not selectable on this hardware.

Test Result

Concurrency dependence: at concurrency 1 the capture ladder is small enough that no shape
routes to opus, and the stock tables pass. The failure only appears once the ladder is wide enough
to reach the affected shapes (observed at M:20/19/18, N:6288). Low-concurrency smoke tests do not
catch this.